IRIX Base Documentation 1998 November/IRIX 6.5.2 Base Documentation November 1998.img/usr/share/catman/u_man/cat1/dmedia/diskalign.z/diskalign

Text File | 1998-10-30 | 35KB | 595 lines

ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



NNNNAAAAMMMMEEEE
     diskalign - XLV Aligned Disk Striping Utility

SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
     ddddiiiisssskkkkaaaalllliiiiggggnnnn ----nnnn<<<<nnnnaaaammmmeeee>>>> ----rrrr<<<<nnnn>>>>[[[[kkkk||||mmmm||||gggg]]]] ----aaaa<<<<nnnn>>>>[[[[kkkk||||mmmm||||gggg]]]] ''''<<<<tttteeeemmmmppppllllaaaatttteeee>>>>'''' ........

DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
     This utility is designed to assist in creating striped XLV disk volumes
     for data streaming applications.  There are many factors that must be
     taken into account when creating a striped XLV volume such as stripe
     alignment, restrictions imposed by a filesystem on the volume and by the
     operating system I/O functions such as _r_e_a_d_v(). This tool, in conjunction
     with _d_i_s_k_p_r_e_p and _d_i_s_k_p_e_r_f will help extract maximum performance from a
     striped XLV disk configuration for data streaming applications.

     The output of _d_i_s_k_a_l_i_g_n can be piped directly into _x_l_v__m_a_k_e to create an
     XLV volume.

OOOOPPPPTTTTIIIIOOOONNNNSSSS
     ----nnnn _n_a_m_e
          Specifies the name of the XLV device for the volume which will
          appear in the /dev/xlv directory. This will also be the name used to
          reference this volume from the XLV management tools such as _x_l_v__m_g_r.

     ----rrrr _s_i_z_e[_k|_m|_g]
          Specifies the exact desired I/O request size for a particular
          application in bytes, kilobytes, megabytes or gigabytes ( using
          suffixes ), To achieve correct alignment, _d_i_s_k_a_l_i_g_n may round this
          value up to the nearest appropriate boundary. The final adjusted
          request size will be reflected in the output script for _x_l_v__m_a_k_e.
          For example, in a video streaming application this would be the
          number of bytes per frame.

     ----aaaa _a_l_i_g_n_m_e_n_t[_k|_m|_g]
          Specifies the required alignment for the request size in bytes,
          kilobytes, megabytes or gigabytes ( using suffixes ). This is a
          critically important hardware and application dependent parameter.
          See the section below for the details on choosing an appropriate
          alignment size.

     <<<<tttteeeemmmmppppllllaaaatttteeee>>>>
          Specifies all the disk devices which compose this XLV striped volume
          and the order in which they appear. This template format is
          described below.  Because the shell interprets the square brackets
          used in the device template syntax, you must enclose each template
          string inside single quotes. Any number of template arguments may be
          supplied.

OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW
     This tool is designed to make life easier when configuring disks into a
     striped XLV volume for high performance data streaming applications. For
     the purpose of this tool, a data streaming application is characterized



                                                                        PPPPaaaaggggeeee 1111






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



     by a I/O requests of a fixed size ( or multiple of a fixed request size
     ). Obvious examples of such applications are uncompressed video streaming
     to or from disk, database tiled texture paging and telemetry applications
     with very high disk bandwidth requirements.

     To ensure maximum performance there are many factors which must be taken
     into account including :

          o Hardware requirements and constraints.
          o Kernel disk driver constraints.
          o XLV striped driver operation.
          o Page alignment constraints of readv()/writev().
          o Alignment constraints imposed by using direct I/O.
          o Application specific requirements.

     To satisfy all these constraints, compromises have to be made which
     ultimately culminate in using an I/O request size rounded up to an
     appropriate alignment boundary. That is, you have to add padding to each
     element of your data set ( eg. frame of video ) to guarantee alignment,
     and hence optimal disk performance, for all elements of the data set.

     Calculation of this padding factor is not a trivial problem. This tool
     automates the process all the way to the point of generating the
     appropriate script file for _x_l_v__m_a_k_e to create the volume.

RRRREEEEQQQQUUUUEEEESSSSTTTT SSSSIIIIZZZZEEEE AAAALLLLIIIIGGGGNNNNMMMMEEEENNNNTTTT
     Choosing an appropriate alignment for the request size is critical to
     achieving optimal disk performance. Badly chosen values can cause poor
     performance or even violate hard constraints which will cause I/O errors
     to be returned to the application.  The rule for choosing a correct
     alignment size is to take the maximum of all the following values :

     DDDDeeeevvvviiiicccceeee ddddeeeeppppeeeennnnddddeeeennnntttt mmmmiiiinnnniiiimmmmuuuummmm rrrreeeeqqqquuuueeeesssstttt ssssiiiizzzzeeee
          Check whether the disk devices have any constraints on the minimum
          allowed request size.  For example, MaxStrat Gen5 disk arrays can be
          configured with 64KB block size which is the minimum allowed
          transfer size.

     FFFFiiiilllleeeessssyyyysssstttteeeemmmm bbbblllloooocccckkkk ssssiiiizzzzeeee
          The use of direct I/O requires that the request size be a multiple
          of the filesystem block size.  This block size is chosen at the time
          the filesystem is built with _m_k_f_s.

          eg. # mkfs -b size=16384 /dev/xlv/video

     SSSSyyyysssstttteeeemmmm ppppaaaaggggeeee ssssiiiizzzzeeee iiiiffff uuuussssiiiinnnngggg _r_e_a_d_v(((())))////_w_r_i_t_e_v(((())))
          If the application makes use of the scatter/gather I/O mechanism
          provided by the _r_e_a_d_v()/_w_r_i_t_e_v() system calls then the operating
          system requires all requests to be system page size aligned.  The
          system page size is typically 16KB, but can be determined from the
          shell using _s_y_s_c_o_n_f with the PAGESIZE argument.




                                                                        PPPPaaaaggggeeee 2222






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



DDDDEEEEVVVVIIIICCCCEEEE TTTTEEEEMMMMPPPPLLLLAAAATTTTEEEE FFFFOOOORRRRMMMMAAAATTTT
     The device template format is a syntax for specifying lists of devices in
     a very compact and convenient way.  A template is a string with embedded
     numeric patterns, which allow a single string to represent many device
     names.  This is expecially useful specifying groups of disk devices
     making up a striped volume.  An example of a template representing
     partition 7 on disks 1 to 4 on SCSI controller 9 is :

          ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss9999dddd[[[[1111----4444]]]]ssss7777

     The template syntax allows numeric patterns to be inserted into a string
     using the square bracket delimiters. The pattern may also contain control
     sequences inside the square brackets which modify the way the pattern is
     evaluated. For example, ''''[[[[zzzz3333,,,,1111----3333]]]]'''' causes all numbers generated by this
     pattern to be zero padded to three digits and thus represents the
     sequence "000000001111","000000002222","000000003333".

     The supported pattern controls are as follows :

     <<<<nnnn>>>>  This is the simplest of components and simply represents a single
          number. Any number of these controls may appear in a pattern.  For
          example,

          ''''tttteeeesssstttt[[[[1111,,,,55557777,,,,11113333]]]]'''' produces "tttteeeesssstttt1111","tttteeeesssstttt55557777","tttteeeesssstttt11113333"

     <<<<mmmm>>>>----<<<<nnnn>>>>
          Appends the range of numbers from mmmm to nnnn with increment ( set with
          iiii<<<<nnnn>>>> ) to the sequence.  nnnn may be less mmmm implying that the range
          will run backwards from mmmm to nnnn with specified increment. Note that nnnn
          may not actually appear into the output sequence for increments
          greater than one as no numbers outside the specified range will be
          produced.  For example,

          ''''xxxx[[[[1111----3333,,,,99999999----99997777]]]]'''' produces "xxxx1111","xxxx2222","xxxx3333","xxxx99999999","xxxx99998888","xxxx99997777"

     iiii<<<<nnnn>>>> Sets the increment for all range controls in this pattern.  Only one
          of these controls may appear in a single pattern.

          ''''[[[[iiii3333,,,,1111----8888,,,,666666666666,,,,99999999----99997777]]]]'''' produces "1111","4444","7777","666666666666","99999999"

     zzzz<<<<nnnn>>>> Sets the number of digits to which all numbers produced by the
          pattern will be zero padded.  For example,

          ''''[[[[iiii3333,,,,zzzz3333,,,,1111----5555,,,,666666666666,,,,99999999----99997777]]]]'''' produces "000000001111","000000004444","666666666666","000099999999"

     pppp<<<<nnnn>>>> As multiple patterns may appear in a single template string, it is
          sometimes important to be able to control the order of evaluation of
          the patterns.  This is especially important with when specifying
          disk devices for striping as order of device specification to
          _x_l_v__m_a_k_e is critical to achieve optimal performance.  This control
          sets the priority of evaluation for the pattern. The default
          priority for a pattern is one and evaluation order of patterns with



                                                                        PPPPaaaaggggeeee 3333






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



          equal priority is from right to left in the string. Patterns with
          the lowest priority values are evaluated first. Only one of these
          controls may appear in a single pattern. For example,

          ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss[[[[1111,,,,2222]]]]dddd[[[[3333,,,,4444]]]]ssss7777'''' produces

          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd3333ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd4444ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd3333ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd4444ssss7777"

          whereas ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss[[[[pppp0000,,,,1111,,,,2222]]]]dddd[[[[3333,,,,4444]]]]ssss7777'''' produces

          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd3333ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd3333ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd4444ssss7777"
          "////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd4444ssss7777"

EEEEXXXXAAAAMMMMPPPPLLLLEEEE ####1111 :::: SSSSTTTTRRRRIIIIPPPPIIIINNNNGGGG FFFFOOOORRRR VVVVIIIIDDDDEEEEOOOO SSSSTTTTRRRREEEEAAAAMMMMIIIINNNNGGGG
     In this example it will be shown how to configure an XLV striped volume
     for storing uncompressed CCIR-601 NTSC fields. These fields will be
     stored in native YCrCb ( sometimes referred to as YUV ) color space which
     requires 2 bytes per pixel. To achieve real time playback at 60 fields
     per second the volume will have to sustain a bandwidth of approximately
     22MB/s. The volume will be configured using four UltraSCSI disks on the
     internal controller 0 of an Origin2000 or Onyx2.

   PPPPaaaarrrraaaammmmeeeetttteeeerrrrssss
     The parameters of interest for configuration of the XLV striped volume
     are as follows :

          IIIImmmmaaaaggggeeee wwwwiiiiddddtttthhhh   ==== 777722220000 ppppiiiixxxxeeeellllssss (((( CCCCCCCCIIIIRRRR----666600001111 ))))
          IIIImmmmaaaaggggeeee hhhheeeeiiiigggghhhhtttt  ==== 222244443333 ppppiiiixxxxeeeellllssss (((( CCCCCCCCIIIIRRRR----666600001111 NNNNTTTTSSSSCCCC ffffiiiieeeelllldddd ))))
          BBBByyyytttteeeessss////ppppiiiixxxxeeeellll   ==== 2222   bbbbyyyytttteeeessss  (((( YYYYCCCCrrrrCCCCbbbb ccccoooolllloooorrrr ssssppppaaaacccceeee ))))
          CCCCoooonnnnttttrrrroooolllllllleeeerrrrssss   ==== 1111   UUUUllllttttrrrraaaaSSSSCCCCSSSSIIII
          DDDDiiiisssskkkkssss////CCCCttttllllrrrr    ==== 4444   UUUUllllttttrrrraaaaSSSSCCCCSSSSIIII ddddiiiisssskkkkssss

   CCCCaaaallllccccuuuullllaaaatttteeee RRRReeeeqqqquuuueeeesssstttt SSSSiiiizzzzeeee
     The first parameter we have to calculate is the size of a single CCIR-601
     NTSC field.  The calculation is simple :

          RRRReeeeqqqquuuueeeesssstttt SSSSiiiizzzzeeee ==== WWWWiiiiddddtttthhhh **** HHHHeeeeiiiigggghhhhtttt **** BBBByyyytttteeeessss____PPPPeeeerrrr____PPPPiiiixxxxeeeellll
                       ==== 777722220000 **** 222244443333 **** 2222
                       ==== 333344449999999922220000 bbbbyyyytttteeeessss////ffffiiiieeeelllldddd

   DDDDeeeetttteeeerrrrmmmmiiiinnnneeee AAAAlllliiiiggggnnnnmmmmeeeennnntttt SSSSiiiizzzzeeee
     Now although we would like to use a 4KB filesystem block size, we would
     also like to have the flexibility of using scatter/gather DMA to improve
     performance. This requires alignment to 16KB page size boundaries for I/O
     requests.  So, we must choose an alignment factor of 16KB.





                                                                        PPPPaaaaggggeeee 4444






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



   CCCCoooonnnnssssttttrrrruuuuccccttttiiiinnnngggg tttthhhheeee XXXXLLLLVVVV VVVVoooolllluuuummmmeeee
     Here is the transcript for construction of this volume.

     #### ddddiiiisssskkkkaaaalllliiiiggggnnnn ----nnnn vvvviiiiddddeeeeoooo ----rrrr333344449999999922220000 ----aaaa11116666kkkk ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss0000dddd[[[[2222----5555]]]]ssss7777'''' |||| tttteeeeeeee
     ////ttttmmmmpppp////xxxxllllvvvv....ssssccccrrrriiiipppptttt
     # Number of devices     =       4
     # Filesystem block size =   16384 bytes
     # Desired request size  =  349920 bytes
     # Aligned request size  =  360448 bytes
     # Alignment padding     =   10528 bytes
     # Padding I/O overhead  =    3.01 %
     #
     vol video
     data
     plex
     ve -force -stripe -stripe_unit 176 \
     /dev/dsk/dks0d2s7 \
     /dev/dsk/dks0d3s7 \
     /dev/dsk/dks0d4s7 \
     /dev/dsk/dks0d5s7
     end
     exit
     #### xxxxllllvvvv____mmmmaaaakkkkeeee <<<< ////ttttmmmmpppp////xxxxllllvvvv....ssssccccrrrriiiipppptttt
     video
     video.data
     video.data.0
     video.data.0.0
     Object specification completed
     #### mmmmkkkkffffssss ////ddddeeeevvvv////xxxxllllvvvv////vvvviiiiddddeeeeoooo
     #### mmmmkkkkddddiiiirrrr ////vvvviiiiddddeeeeoooo
     #### cccchhhhmmmmoooodddd 777777777777 ////vvvviiiiddddeeeeoooo
     #### mmmmoooouuuunnnntttt ////ddddeeeevvvv////xxxxllllvvvv////vvvviiiiddddeeeeoooo ////vvvviiiiddddeeeeoooo

   IIIInnnntttteeeerrrrpppprrrreeeettttaaaattttiiiioooonnnn ooooffff RRRReeeessssuuuullllttttssss
     As can be seen in the script comments, padding was added to the size of
     each field to achieve the required alignment.  The application must read
     or write 360448 bytes for each field, which includes the field data as
     well as the padding to maintain alignment and hence optimal disk
     performance for this configuration.  The padding is only giving a 3.01%
     overhead in size and bandwidth.

EEEEXXXXAAAAMMMMPPPPLLLLEEEE ####2222 :::: SSSSTTTTRRRRIIIIPPPPIIIINNNNGGGG FFFFOOOORRRR HHHHIIIIGGGGHHHH RRRREEEESSSSOOOOLLLLUUUUTTTTIIIIOOOONNNN SSSSTTTTRRRREEEEAAAAMMMMIIIINNNNGGGG
     In this example it will be shown how to configure an XLV striped volume
     for storing uncompressed high resolution images for real time preview
     purposes.  The resolution of the images is 2048 pixels by 1120 lines. The
     images are stored using 8-bit RGB color space which requires 3 bytes per
     pixel.  The disk storage subsystem is composed of 20 fibre channel disks
     connected to a dual channel XIO fibre channel adapter, with 10 disks
     connected to each channel.






                                                                        PPPPaaaaggggeeee 5555






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



   PPPPaaaarrrraaaammmmeeeetttteeeerrrrssss
     The parameters of interest for configuration of the XLV striped volume
     are as follows :

          IIIImmmmaaaaggggeeee wwwwiiiiddddtttthhhh   ==== 2222000044448888 ppppiiiixxxxeeeellllssss
          IIIImmmmaaaaggggeeee hhhheeeeiiiigggghhhhtttt  ==== 1111111122220000 lllliiiinnnneeeessss
          BBBByyyytttteeeessss////ppppiiiixxxxeeeellll   ==== 3333    bbbbyyyytttteeeessss  (((( 8888----bbbbiiiitttt RRRRGGGGBBBB ccccoooolllloooorrrr ssssppppaaaacccceeee ))))
          CCCCoooonnnnttttrrrroooolllllllleeeerrrrssss   ==== 2222    XXXXIIIIOOOO FFFFiiiibbbbrrrreeee CCCChhhhaaaannnnnnnneeeellll
          DDDDiiiisssskkkkssss////CCCCttttllllrrrr    ==== 11110000   FFFFiiiibbbbrrrreeee CCCChhhhaaaannnnnnnneeeellll ddddiiiisssskkkkssss

   CCCCaaaallllccccuuuullllaaaatttteeee RRRReeeeqqqquuuueeeesssstttt SSSSiiiizzzzeeee
     The first parameter we have to calculate is the size of a single high
     resolution frame.  The calculation is simple :

          RRRReeeeqqqquuuueeeesssstttt SSSSiiiizzzzeeee ==== WWWWiiiiddddtttthhhh **** HHHHeeeeiiiigggghhhhtttt **** BBBByyyytttteeeessss____PPPPeeeerrrr____PPPPiiiixxxxeeeellll
                       ==== 2222000044448888 **** 1111111122220000 **** 3333
                       ==== 6666888888881111222288880000 bbbbyyyytttteeeessss////ffffrrrraaaammmmeeee

   DDDDeeeetttteeeerrrrmmmmiiiinnnneeee AAAAlllliiiiggggnnnnmmmmeeeennnntttt SSSSiiiizzzzeeee
     Because of the large request size we choose a 16KB filesystem block size
     which also makes scatter/gather DMA possible.  Thus, we select a 16KB
     alignment.

   CCCCoooonnnnssssttttrrrruuuuccccttttiiiinnnngggg tttthhhheeee XXXXLLLLVVVV VVVVoooolllluuuummmmeeee
     Here is the transcript for construction of this volume.

     #### ddddiiiisssskkkkaaaalllliiiiggggnnnn ----nnnn ffffiiiillllmmmm ----rrrr6666888888881111222288880000 ----aaaa11116666kkkk ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss[[[[pppp0000,,,,11110000,,,,11111111]]]]dddd[[[[0000----9999]]]]ssss7777'''' ||||
     tttteeeeeeee ////ttttmmmmpppp////xxxxllllvvvv....ssssccccrrrriiiipppptttt
     # Number of devices     =      20
     # Filesystem block size =   16384 bytes
     # Desired request size  = 6881280 bytes
     # Aligned request size  = 6881280 bytes
     # Alignment padding     =       0 bytes
     # Padding I/O overhead  =    0.00 %
     #
     vol film
     data
     plex
     ve -force -stripe -stripe_unit 672 \
     /dev/dsk/dks10d0s7 \
     /dev/dsk/dks11d0s7 \
     /dev/dsk/dks10d1s7 \
     /dev/dsk/dks11d1s7 \
     /dev/dsk/dks10d2s7 \
     /dev/dsk/dks11d2s7 \
     /dev/dsk/dks10d3s7 \
     /dev/dsk/dks11d3s7 \
     /dev/dsk/dks10d4s7 \
     /dev/dsk/dks11d4s7 \
     /dev/dsk/dks10d5s7 \





                                                                        PPPPaaaaggggeeee 6666






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



     /dev/dsk/dks11d5s7 \
     /dev/dsk/dks10d6s7 \
     /dev/dsk/dks11d6s7 \
     /dev/dsk/dks10d7s7 \
     /dev/dsk/dks11d7s7 \
     /dev/dsk/dks10d8s7 \
     /dev/dsk/dks11d8s7 \
     /dev/dsk/dks10d9s7 \
     /dev/dsk/dks11d9s7
     end
     exit
     #### xxxxllllvvvv____mmmmaaaakkkkeeee <<<< ////ttttmmmmpppp////xxxxllllvvvv....ssssccccrrrriiiipppptttt
     film
     film.data
     film.data.0
     film.data.0.0
     Object specification completed
     #### mmmmkkkkffffssss ----bbbb ssssiiiizzzzeeee====11116666333388884444 ////ddddeeeevvvv////xxxxllllvvvv////ffffiiiillllmmmm
     #### mmmmkkkkddddiiiirrrr ////ffffiiiillllmmmm
     #### cccchhhhmmmmoooodddd 777777777777 ////ffffiiiillllmmmm
     #### mmmmoooouuuunnnntttt ////ddddeeeevvvv////xxxxllllvvvv////ffffiiiillllmmmm ////ffffiiiillllmmmm

   IIIInnnntttteeeerrrrpppprrrreeeettttaaaattttiiiioooonnnn ooooffff RRRReeeessssuuuullllttttssss
     As can be seen in the script comments, we were fortunate in that the
     frame size was already aligned correctly. Because of this, the requests
     we already aligned and hence we have no padding overhead !!

TTTTIIIIPPPPSSSS AAAANNNNDDDD TTTTRRRRIIIICCCCKKKKSSSS
     Here are a few tips for getting the most from a disk configuration.

   HHHHoooommmmooooggggeeeennnnoooouuuussss DDDDiiiisssskkkkssss
     Ensure that all the disks in the volume are the same model. The
     performance of the striped volume is directly dependent on the slowest
     disk in the volume. One slow disk can affect the performance of the
     entire volume.

   FFFFiiiirrrrmmmmwwwwaaaarrrreeee RRRReeeevvvviiiissssiiiioooonnnnssss
     Confirm that all the disks in the volume have the same firmware revision.
     Different revisions may have different performance characteristics which
     may adversely affect performance. The firmware revision of a disk can be
     checked with _f_x. The _d_i_s_k_p_r_e_p utility can be used with SGI IBM Scorpion
     UltraSCSI disks to automatically download the latest firmware revision.

   DDDDiiiisssskkkk PPPPaaaarrrraaaammmmeeeetttteeeerrrr SSSSeeeettttttttiiiinnnnggggssss
     Ensure that all disks have the same parameter settings. For example, if
     you enable write buffering on all the disks of a striped XLV volume
     except one, the write performance will be constrained to the performance
     of this single slow disk. The same applies for number of cache segments
     and many other parameters. These can be checked with _f_x.  The _d_i_s_k_p_r_e_p
     utility can be used with SGI IBM Scorpion UltraSCSI disks to
     automatically set all the parameters to SGI manufacturing defaults.




                                                                        PPPPaaaaggggeeee 7777






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



   EEEEnnnnaaaabbbblllleeee WWWWrrrriiiitttteeee BBBBuuuuffffffffeeeerrrriiiinnnngggg
     To achieve good write performance you can enable write buffering on all
     the disks in the volume.  Note that this does open a window of
     vulnerability for disk corruption so you should carefully evaluate the
     data integrity needs of your application before enabling write buffering.
     This can be set manually using _f_x or automatically using the _d_i_s_k_p_r_e_p
     utility if using SGI IBM Scorpion UltraSCSI disks.

   SSSSeeeetttt NNNNuuuummmmbbbbeeeerrrr OOOOffff CCCCaaaacccchhhheeee SSSSeeeeggggmmmmeeeennnnttttssss
     The effect of the parameter is disk vendor specific, but is applicable to
     the SGI IBM Scorpion UltraSCSI disks. For data streaming applications
     setting the number of cache segments to 1 can give a significant
     performance boost due to much better onboard disk cache utilization. This
     can be set manually using _f_x or automatically using the _d_i_s_k_p_r_e_p utility
     if using SGI IBM Scorpion UltraSCSI disks.

   IIIItttteeeerrrraaaatttteeee CCCCoooonnnnttttrrrroooolllllllleeeerrrrssss FFFFiiiirrrrsssstttt
     Because of the way the striped XLV driver works, it is much more
     efficient to iterate across controllers first and disks second when
     specifying devices to be striped. The pattern priority control pppp<<<<nnnn>>>> can
     be used to achieve this. To illustrate, the two templates below specify
     the same devices for a volume, but in different orders. The volume
     generated by the first pattern achieves better performance than the the
     second.

          ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss[[[[pppp0000,,,,1111----3333]]]]dddd[[[[4444----6666]]]]ssss7777'''' which represents

               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd6666ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd6666ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd6666ssss7777

          performs better than ''''////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss[[[[1111----3333]]]]dddd[[[[4444----6666]]]]ssss7777''''

               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss1111dddd6666ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss2222dddd6666ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd4444ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd5555ssss7777
               ////ddddeeeevvvv////ddddsssskkkk////ddddkkkkssss3333dddd6666ssss7777

   VVVVeeeerrrriiiiffffyyyy VVVVoooolllluuuummmmeeee PPPPeeeerrrrffffoooorrrrmmmmaaaannnncccceeee
     The _d_i_s_k_p_e_r_f utility can be used to measure the performance of striped
     volume once it has been configured. This will allow you to determine in



                                                                        PPPPaaaaggggeeee 8888






ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))                                                      ddddiiiisssskkkkaaaalllliiiiggggnnnn((((1111))))



     advance if a configuration is adequate for a particular application.

SSSSEEEEEEEE AAAALLLLSSSSOOOO
     diskprep(1M), diskperf(1M), read(2), write(2), readv(2), writev(2),
     xlv_make(1M), mkfs(1M), sysconf(1)

NNNNOOOOTTTTEEEESSSS
     None

AAAAUUUUTTTTHHHHOOOORRRR
     Will McGovern ( [e-mail] )
     Advanced Entertainment Systems Division
     Silicon Graphics Inc.










































                                                                        PPPPaaaaggggeeee 9999